三天下來我們確認了:市場要什麼(Day 02)、誰負責什麼(Day 03)。今天是第一部曲的收尾,也是我覺得最實用的一篇——把職缺梳理成您能照著走的路。
「我知道要學 MLOps 了,然後呢?」
這是我最常思考的問題,而多數答案都不見得符合實際,因為多半收到的是技術清單:Docker、K8s、MLflow、Airflow、Terraform……看起來很完整,但沒有回答到我期待的三個關鍵問題:
今天這篇就試著回答這三個問題。
📊 職缺訊號
學習順序應該按任務訊號的頻率 × 您的缺口排序,而不是依照「技術難度」排序。同樣是 MLOps,平臺與基礎設施出現在 58.5% 的職缺、模型版本與實驗管理只有 7.2%——不是後者不重要,而是當你時間有限時,前者能讓你先拿到面試。
絕大多數要進這兩個職務的人,來自三個地方。您的既有優勢與待補缺口完全不同:

圖 4-1:三條主流轉職路線的既有優勢與待補缺口(依 2026 年職缺任務訊號與常見團隊分工整理的示意性歸納)。綠色是可直接遷移的優勢,紅色是本系列要補的缺口。
路線 A:後端/DevOps → MLOps/LLMOps。 您已經有容器、CI/CD、監控、API 服務的底子——這是最短的路。您缺的不是工程能力,是「ML 特有的那些會故障的地方」:資料會漂移、特徵在訓練與線上會不一致、模型會無聲失效。Day 09、11、14 是你的重點。
路線 B:資料科學家 → MLOps/LLMOps。 您懂模型與資料,缺的是工程紀律與系統思維:容器、K8s、IaC、SLO。這條路的難處不是學不會,是心態轉換——從「這個模型指標更好」轉換成「這個系統半夜壞了誰處理」。Day 12、13、15 是你的重點。
路線 C:前/後端 → 生成式 AI 應用。 您會做系統整合,缺的是LLM 的行為特性:它會胡說、輸出不確定、每次呼叫都在花錢、還可能被使用者的輸入騙走。Day 07、18–20、24–25 是你的重點。
有了缺口清單,接下來是排序。我們梳理成三個原則:
原則一:能不能動手,優先於懂不懂原理。 先讓一個東西在電腦上跑起來,再回頭理解為什麼。這是因為跑過比較容易記住。所以 Day 05 會先提供工程基礎,Day 06、07 才補理論。
原則二:先學「會被別人依賴」的,再學「只有自己用到」的。 容器化的優先序高於實驗追蹤,因為前者是別人接您工作的介面,後者是自己的工作習慣。這也對應了任務訊號的高低。
原則三:先建立回饋迴路,再談優化。 監控與評測要早於效能最佳化。如果連自己有沒有變好都不知道,又該如何談優化。也因此會安排 Day 14 談監控, Day 15 再談成本優化;Day 20 會談評測、Day 23 再談微調。

圖 4-2:30 天連載路線圖(依任務訊號配比規劃的示意排程)。Day 08 分流、Day 24 合流。
完整版: 照順序走,Day 28 的綜合專題會把前 27 天串起來。
主軸一速成(時間有限、想轉 MLOps): Day 01–04 → 05–06 → 08–15 → 24、26、27 → 28–30。可跳過 Day 07、16–23 的細節,但 Day 18 與 Day 21 建議略讀,因為您未來要支援的就是這些系統。
主軸二速成(時間有限、想做生成式 AI 應用): Day 01–04 → 05、07 → 16–23 → 24–27 → 28–30。可跳過 Day 09–11,但 Day 12–14 建議略讀——不懂部署與監控的應用工程師,做出來的東西上線也不好控制。
週末版(平日沒空): 每個週末處理一個部曲,六週走完。優先做每篇的「動手」段落,「取捨」段落當睡前讀物。
主管/教學者版: Day 01–04(為什麼要投資這個能力)+ Day 29(怎麼驗收)+ Day 30(怎麼規劃團隊路徑)。中間 25 天當作能力清單的細目。
搭配一個可勾選的能力檢核,每完成一項就打勾——這份清單直接對應面試會問的東西:
【共同地基】
□ 能寫一個 multi-stage Dockerfile 把服務打包成 500MB 以下的映像
□ 能說明 .env 與金鑰管理的正確做法,且從不把金鑰寫進程式碼
□ 能講清楚「訓練/驗證/測試」為什麼要切、切錯會怎樣
□ 能估算一次 LLM 呼叫的成本,並說出哪一段最貴
【主軸一 MLOps】
□ 能用 MLflow 追蹤實驗並註冊模型,服務端以 alias 取用
□ 能寫一條含品質門檻的 CI 流程,模型沒過門檻不得上線
□ 能在本地 kind 叢集部署服務並設定 HPA
□ 能對 API 壓測並讀懂 P50/P95/P99,據此訂 SLO
□ 能用 PSI 或 KS 檢定偵測漂移,並說明門檻怎麼定
【主軸二 生成式 AI】
□ 能建一個含混合檢索與來源引用的 RAG 系統
□ 能手刻一個具工具呼叫與迭代上限的 ReAct agent
□ 能建 20 題以上的評測集,並算出 LLM 評審與人工標註的一致性
□ 能說明提示注入的四層防禦,並實作其中至少兩層
□ 能判斷一個需求該用微調、RAG 還是提示工程,並說出理由
以下這些,在您拿到第一份相關工作之前,可以先不碰,在策略上設定明確的止損點:
| 先不學 | 為什麼 | 什麼時候再學 |
|---|---|---|
| 自建 Kubernetes 叢集 | 先求會用(部署、除錯),建叢集是平臺團隊的事,還不急 | 進入約有 8 人以上規模團隊、要做內部平臺時 |
| 從頭訓練大模型 | 幾乎沒有職缺要求,成本也不是個人負擔得起,這是市場說的不是我說的 | 進入模型研發團隊時(極少數) |
| 全參數微調 | 90% 的客製需求用 RAG 或 LoRA 就能解 | 有明確風格/格式需求且已試過提示工程後(Day 23) |
| 多代理框架(AutoGen、CrewAI 等) | 多數需求用確定性工作流更穩、更便宜 | 單一代理已經做好,且確實遇到需要協作的場景(Day 22) |
| 分散式訓練(DDP/FSDP) | 對應職缺比例極低 | 要訓練 10B 以上模型時 |
| 各家雲端的專屬服務認證 | 觀念相通,工具可換;先學開源版本理解原理 | 確定要進的公司用哪一朵雲之後 |
⚠️ 但這三件事不能省
可重現、監控、評測。 這三項在每份職缺裡都不是最顯眼的關鍵字,卻是資深與初階的實質差別。它們的共同點是:做了不會有人稱讚,沒做遲早會出事。
第一部曲結束,明天進入地基。我們從最實際的地方開始:您的開發環境。Python 環境、Git 在 ML 專案的特殊性(大型檔案、資料、金鑰)、第一個 Dockerfile,以及一個太多人踩的坑——把 API 金鑰推上 GitHub。